Conversation
- We now get warnings about unnecessary parentheses around `dyn` types. - Spelling of `sf.name.prefer_remapped_unconditionaly` was fixed (now ends in `lly`). - `Pointer::into_parts` has been replaced with `Pointer::prov_and_relative_offset`.
- `BuilderMethods::dynamic_alloca` was removed.
- `TargetDataLayout::pointer_{size,align}` were changed from fields to
methods.
- `AddressSpace::DATA` was renamed `AddressSpace::ZERO`.
- `run_fat_lto`, `optimize_fat`, and `autodiff` were merged into `run_and_optimize_fat_lto`, and the parameters were changed. - `run_thin_lto` parameters were changed. - `codegen` parameters were changed. - `LtoModuleCodegen` was removed. - Minor error message changes: - Some line number changes in rustc. - Some error message wording tweaks. The LTO changes occurred in rust-lang/rust PR 143388 and PR 144062.
- `tcx.get_attrs_unchecked(...)` was replaced with `tcx.get_all_attrs(...)`. - `run_link` has been removed. - `BuilderMethods::tail_call` was added. It's currently `todo!()`. - Adjust expected test outputs for very minor error message formatting changes. - And update to glam 0.30.8.
fee1-dead
requested review from
Firestar99,
LegNeato,
eddyb and
schell
as code owners
fee1-dead
force-pushed
the
update-toolchain
branch
from
04826c2 to
5a8cdc6
Compare
|
The |
|
Apparently it was codegenning for https://doc.rust-lang.org/src/core/ptr/const_ptr.rs.html#153 EDIT: more precisely, |
fee1-dead
force-pushed
the
update-toolchain
branch
from
4bba4a3 to
f99a5bc
Compare
|
@fee1-dead I'll review it in a moment, but I've got a question for you: This PR is based on #420, but we've also had someone else attempt to upgrade the toolchain to 2025-11-13 in #460. Now their branch doesn't work as of right now, and their commit list somehow reverts some merged PRs for whatever reason. But still, which one should we go forward with? |
There was a problem hiding this comment.
Looks good to me, then again, I'm not a rustc guy. I just see CI passing and nothing in the changes that jumps out to me. Just one question :D
About #460: it looks like @dvdplm jumped immediately to 2025-11-02 and later to 2025-11-13, so we should be able to rebase their work on top of this and work from there. (I'll try to rebase it rn)
| // HACK(fee1-dead): `MaybeUninit` uses a union which we don't have very good support yet. Replacing all calls to it | ||
| // with an `Undef` serves the same purpose and fixes compiler errors | ||
| if instance_def_id.is_some_and(|did| { | ||
| self.tcx | ||
| .is_diagnostic_item(rustc_span::sym::maybe_uninit_uninit, did) | ||
| }) { | ||
| return self.undef(result_type); | ||
| } |
There was a problem hiding this comment.
What an interesting solution, I like it!
| fn tail_call( | ||
| &mut self, | ||
| _llty: Self::Type, | ||
| _fn_attrs: Option<&CodegenFnAttrs>, | ||
| _fn_abi: &FnAbi<'tcx, Ty<'tcx>>, | ||
| _llfn: Self::Value, | ||
| _args: &[Self::Value], | ||
| _funclet: Option<&Self::Funclet>, | ||
| _instance: Option<ty::Instance<'tcx>>, | ||
| ) { | ||
| todo!() | ||
| } |
There was a problem hiding this comment.
This is from @nnethercote 's commits. CI is passing, so I assume this is never called, but why not make tail_call call call?
|
I've rebased #460 onto this PR and split it into:
|
3 participants
based on #420